Software modules interact by exporting a list of functions (API) by one module, and calling this API by another module. Thus, a program written by vendor A can load a library/module (possibly provided by another vendor, vendor B) that provides services to the main program. Both the program and the library are typically provided to the user in binary form (i.e. without the source code). The user may want to modify the way in which the software works, but the source code may not be available. Still, by knowing the API exported by the library, the user can interject its own code between the main program and the library. This is done by a technique called “patching” (or “hooking”). There are several variants, but the essence is that a user code can be run before, instead or after any function exported by the library (and invoked by the main program).
The aforementioned patching or hooking technique has many legitimate uses, such as debugging, tweaking (e.g. add security checks, add Y2K checks, or other checks), etc. On the other hand, it is a very effective way to maliciously modify the manner in which legitimate browsing software behaves. In such case, malware first infects a user's PC, and then it modifies the user's browser (through patching) so that the malware is able to read user data and modify it.
Another consideration is that, oftentimes, the same function/API is patched by several “players”—some of which may be legitimate, and some not.
It should be stressed that patching techniques have been widely known for decades, and are applicable to a vast array of operating systems and architectures. For simplicity, for illustrative purposes and without loss of generality, the below text describes patching for Windows 32 bit architecture (Win32), but the invention is applicable to many other platforms and architectures.
There are several well-known ways in which patching can be applied:                EAT patching: the original function address in the export table (of the exporting module) is replaced with an address for the surrogate function (which may, or may not call the original function). Any module that imports this module after patching is affected.        IAT patching: the original function address in the import table (of the importing module) is replaced with an address for the surrogate function (which may, or may not call the original function). Only the module whose IAT is modified is affected.        In-line patching: a branching instruction is written in the beginning of the function code (the original code is first saved). The target of the branching instruction is the surrogate function. The surrogate function may return control to the caller, or execute the saved instructions and branch back to the original function.        
There are benefits and drawbacks to each patching method, which would not be discussed herein in detail for the sake of brevity and which are well known to the skilled person.